---
title: 迭代三
sidebar_position: 0
---

## 限界上下文
迭代三里第一个要讲的是“限界上下文”。当系统比较大，开发人员比较多的时候，我们就要考虑模型的拆分了。


限界上下文就是一种通过划分模型边界，分而治之的手段。一个上下文，大体上可以理解为一个子系统。


说到这你可能有点疑问，子系统的概念早就存在了，那么《领域驱动设计》的作者为什么又要提出“限界上下文”这个听起来有点古怪的概念呢？


如果翻翻《领域驱动设计》原书，我们会看到讲限界上下文这一章（第 14 章）叫做“保持模型的完整性”。为什么这一章不叫“划分模型边界”之类的名字呢？而且，书中把这一章归为“战略设计”，DDD 中所谓战略和战术又有什么区别呢


事实上，限界上下文是化解大型系统的利器，也是架构设计的基础。比如说微服务就可以基于限界上下文来设计。这个迭代，我们将通过限界上下文的建模 、架构设计、代码实现等层面，带你弄清楚限界上下文的概念和用法。

## CQRS

第二个知识点是 CQRS（Command Query Responsibility Segration）。中文可以叫做“命令查询职责分离”。这是一种架构模式，可以和 DDD 配合起来，处理查询功能。


我们在前两个迭代没有涉及太多查询的内容。这个迭代里，我们会指出仅仅使用领域模型的思路实现查询功能有什么不足，还会讲解怎样通过 CQRS 解决问题。


## 分析模式初探

目前课程里我们已经学到的技能可以解决中等复杂的需求。但如果需求更加复杂，可能需要更抽象的建模技能。这种技能不容易掌握，而分析模式给我们提供了一条掌握抽象复杂建模技能的途径。


## 迭代三的挑战和需求

下面，我们把目光投注到“卷卷通”公司，了解一下这个迭代开发团队遇到的新挑战。
### 项目范围扩大的挑战

我们的“卷卷通”产品自推向市场后，受到大量客户的欢迎，市场需求火爆。同时，越来越多的需求，也让系统开始膨胀，团队规模也变大了。由开始的 4、5 个人，发展到了将近 20 个人。这时候团队发现了几个问题。

一是系统变得不容易理解了。过去，每个开发人员都几乎理解系统的所有细节，现在，没有人懂系统的所有部分，有时就会影响后续的工作。

二是沟通成本升高了，由于每个人只了解的系统的一部分，团队成员之间经常发生误解，难以快速达成一致。

三是系统的缺陷增加了。修改系统时常常牵一发而动全身，修改一个部分，不小心就会碰到其他部分，发生意想不到的错误。

不难预测，随着系统规模的进一步增大，这些挑战必然更加严峻，那么团队该怎么办呢？

下面再看一下新的业务需求。
#### 人员和组织管理

在人员和组织管理方面，由于使用我们系统的企业多种多样，需求变得非常灵活。

第一个需求是，员工可以属于多个组织。比如说对于一些矩阵式管理的企业，一个员工既属于他所在的行政组织，又属于某个临时组建的项目团队，还属于某个兴趣小组。

第二个需求是，一个组织可以处于多个组织体系里。比如说，一个集团公司的总公司有信息技术部，集团的分公司也有信息技术部。那么，分公司的信息技术部，既受到分公司的管理，也受到总公司信息技术部的管理。这时候，分公司信息技术部就处在两个组织体系，或者说两颗组织树里面了。

#### 需求二

在工时管理方面，又新增了两个需求。

第一个需求是，接入假期系统信息。有一些企业有专门的假期管理系统，他们希望把员工休假信息也纳入工时管理。比如说，小张在 2 月 1 日休了年假，那么在工时管理系统也能看到这个信息，这样，小张花费的所有时间就都可以在工时系统里看到了，也便于相关部门进行各种统计分析。

第二个需求是，查询和统计。比如说，给定一个时间段，可以看到某员工在这个时期内各个工时项的累计工时信息。或者给定一个项目，可以看到这个项目下各成员的累计工时信息。

我把上面的需求汇总到一张表里，你可以看一下，方便后面的实战。


<img src="https://wkq-img.oss-cn-chengdu.aliyuncs.com/20241212005810.png"/>